Enterprises have grown increasingly reliant on computing systems to accomplish mission-critical tasks. Indeed, enterprises expend vast amounts of resources dedicated to deploying and supporting servers and other processing systems, as availability of sufficient computing resources is critical to enterprise performance. With increasing complexity and number of applications typically deployed in business environments today, providing sufficient computing resources to meet business needs in a cost effective manner poses many challenges.
The workload on a typical server implementation can vary dramatically throughout the day. In fact, demand for one or more applications, and therefore the processing and I/O resources requirements to effectively support these applications, can shift and vary considerably throughout a typical business day. Many application server implementations usually involve building out the infrastructure either to peak loads or to average loads. Building to peak loads can mean a massive over-commitment of resources. This over-commitment can be fairly large when the management and operational costs of the additional servers is included. Building out the infrastructure to the average load is a common approach for many application implementations, but can have even larger productivity costs when demand spikes. For example, in the case of email application servers, slow email access and error messages are frustrating for users and, at times, can lead to confusing email conversations as messages are delivered out of order. In extreme cases, where disk I/O has become too slow to access the database, the mail application server services can fail, disrupting operations all across the enterprise.
In either type of application server deployment implementation, a server application runs on a host that manages its own local or remote storage, and often network access as well. The size of the host server along with its storage and network capacity bounds the number of users this host can support. In the case of email applications, for example, large installations will break up the email user community into blocks of users that can be managed and hosted on each separate server. For example, email server A might service users with last names beginning with letters A through L, and email server 13 will host users whose last names begin with letters M through Z. Scaling such an architecture up (or down) requires physically adding or removing) hardware resources. This approach, however, is generally time consuming and costly, and fails to address the variation in demand across different applications.
In light of the foregoing, a need in the art exists for more flexible server infrastructures where additional I/O resources can be deployed as needed to support varying requirements. Embodiments of the invention substantially fulfill this need.